Support for privileged operation (domain 0)
config XEN_PHYSDEV_ACCESS
- bool "Device-driver domain (physical device access)"
+ bool "Physical device access"
+ default y if XEN_PRIVILEGED_GUEST
+ default n if !XEN_PRIVILEGED_GUEST
help
- Device-driver domain (physical device access)
+ Assume access is available to physical hardware devices
+ (e.g., hard drives, network cards). This allows you to configure
+ such devices and also includes some low-level support that is
+ otherwise not compiled into the kernel.
+
+config XEN_BLKDEV_BACKEND
+ bool "Block-device backend driver"
+ default y if XEN_PHYSDEV_ACCESS
+ default n if !XEN_PHYSDEV_ACCESS
+ help
+ The block-device backend driver allows the kernel to export its
+ block devices to other guests via a high-performance shared-memory
+ interface.
+
+config XEN_NETDEV_BACKEND
+ bool "Network-device backend driver"
+ default y if XEN_PHYSDEV_ACCESS
+ default n if !XEN_PHYSDEV_ACCESS
+ help
+ The network-device backend driver allows the kernel to export its
+ network devices to other guests via a high-performance shared-memory
+ interface.
+
+config XEN_BLKDEV_FRONTEND
+ bool "Block-device frontend driver"
+ default y
+ help
+ The block-device frontend driver allows the kernel to access block
+ devices mounted within another guest OS. Unless you are building a
+ dedicated device-driver domain, or your master control domain
+ (domain 0), then you almost certainly want to say Y here.
+
+config XEN_NETDEV_FRONTEND
+ bool "Network-device frontend driver"
+ default y
+ help
+ The network-device frontend driver allows the kernel to access
+ network interfaces within another guest OS. Unless you are building a
+ dedicated device-driver domain, or your master control domain
+ (domain 0), then you almost certainly want to say Y here.
+
+if XEN_NETDEV_FRONTEND
+config XEN_NETDEV_FRONTEND_PIPELINED_TRANSMITTER
+ bool "Pipelined transmitter (DANGEROUS)"
+ default n
+ help
+ The driver will assume that the backend is pipelining packets for
+ transmission: whenever packets are pending in the remote backend,
+ the driver will not send asynchronous notifications when it queues
+ additional packets for transmission.
+ If the backend is a dumb domain, such as a transparent Ethernet
+ bridge with no local IP interface, it is safe to say Y here to get
+ slightly lower network overhead.
+ If the backend has a local IP interface; or may be doing smart things
+ like reassembling packets to perform firewall filtering; or if you
+ are unsure; or if you experience network hangs when this option is
+ enabled; then you must say N here.
+endif
config XEN_WRITABLE_PAGETABLES
bool "Use writable pagetables"
config PAGESIZED_SKBS
bool
- default y if XEN_PHYSDEV_ACCESS
- default n if !XEN_PHYSDEV_ACCESS
+ default y if XEN_NETDEV_BACKEND
+ default n if !XEN_NETDEV_BACKEND
#config VT
# bool
#define __GFP_NOWARN 0
#endif
+/*
+ * If the backend driver is pipelining transmit requests then we can be very
+ * aggressive in avoiding new-packet notifications -- only need to send a
+ * notification if there are no outstanding unreceived responses.
+ * If the backend may be buffering our transmit buffers for any reason then we
+ * are rather more conservative.
+ */
+#ifdef CONFIG_XEN_NETDEV_FRONTEND_PIPELINED_TRANSMITTER
+#define TX_TEST_IDX resp_prod /* aggressive: any outstanding responses? */
+#else
+#define TX_TEST_IDX req_cons /* conservative: not seen all our requests? */
+#endif
+
static void network_tx_buf_gc(struct net_device *dev);
static void network_alloc_rx_buffers(struct net_device *dev);
np->stats.tx_bytes += skb->len;
np->stats.tx_packets++;
- /* Only notify Xen if there are no outstanding responses. */
- /*
- * KAF (16/9/04): Checking outstanding responses is unsafe, as pending work
- * may be dependent on packets not yet seen by the backend (e.g., he may
- * have a partially-assembled fragmented IP packet). For now, the check is
- * more conservative -- has the backend seen all previous requests?
- */
+ /* Only notify Xen if we really have to. */
mb();
- if ( np->tx->req_cons/*resp_prod*/ == i )
+ if ( np->tx->TX_TEST_IDX == i )
notify_via_evtchn(np->evtchn);
return 0;
projects / xen.git / commitdiff